Reenacting Transactions to Compute their Provenance

Database provenance is essential for auditing, data debugging, understanding transformations, and many additional use cases. While these applications do benefit from state-ofthe-art provenance tracking for queries, most use cases also require provenance for transactional updates. We present the first provenance model for concurrent database transactions. Our model extends the well-known semiring provenance framework with version annotations and update operations. Based on this model, we present the first solution for computing the provenance of database transactions. Our approach can retroactively trace transaction provenance as long as an audit log and time travel functionality are available (both are supported by most DBMS) and without storing any additional information. For a given transaction, our approach constructs a reenactment query that simulates the effect of the transaction. This query is guaranteed to produce the updated versions of tables produced by the transaction and has the same provenance as the original transaction, i.e., it is annotation-equivalent. Using time travel and by adopting well-known techniques for computing the provenance of queries, we can use reenactment to retroactively compute the provenance of transactions. Currently, we support two widely applied concurrency control mechanisms: snapshot isolation and read committed snapshot isolation. We have implemented a prototype on-top of a commercial database system and our experiments confirm that 1) the runtime and storage overhead required to support time-travel and the audit log is tolerable and 2) by applying novel optimizations we can efficiently compute the provenance of large transactions over large data sets.